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@ A first computer workstation 10 includes a voice 
response unit for interfacing to a telephone network. 
The first computer workstation is attached by a com- 
munications link 18 to a second computer work- 
station 20. which includes a server to perform a 
particular voice processing function, such as text to 



speech, voice recognition. FAX-back, and so on. For 
inbound applications the first computer workstation 
forwards the incoming signal over the communica- 
tions link to the server on the second computer 
workstation for real-time processing, whilst for out- 
bound applications, the reverse process occurs. 
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The present invention relates to a distributed 
system for interactively processing telephone calls. 

Many systems are currently available for auto- 
matically providing services or information to call- 
ers over the telephone. Often referred to as voice 
response units (VRUs), such systems have nor- 
mally relied upon the use of dual tone multiple 
frequency (DTMF) signals from push-button tele- 
phones to obtain input from a caller, and respond- 
ed largely with pre-recorded voice segments. How- 
ever, such a system is comparatively limited with 
respect to the sort of dialogue that can be main- 
tained with the caller, given the restricted range of 
acceptable inputs, and the need to pre-record any 
possible responses. 

In order to make such communications more 
natural, and to greatly enhance the flexibility of 
such systems, it is desirable to equip VRUs with 
other voice processing technologies, such as voice 
recognition (to replace the DTMF input), and text to 
speech (TTS) (to replace pre-recorded voice). 
There are many varieties of voice recognition that 
might be considered: for example, voice recogni- 
tion may operate for discrete words or for continu- 
ous speech, and may be speaker dependent, or 
speaker independent. Recognition vocabularies can 
range from perhaps 12 words (typically ten digits 
plus a couple of control words) to many thousands. 
Likewise, there is a considerable range of TTS 
technologies available. 

Voice recognition and TTS applications tend to 
be computationally very intensive; for example, full 
speaker-independent, large vocabulary voice rec- 
ognition typically requires 100 Mips of digital signal 
processing power. The requirement becomes even 
more acute when it is remembered that a VRU 
may handle perhaps 100 telephone lines simulta- 
neously, lead to a potential maximum processing 
requirement of 10 Gips. For this reason most com- 
mercial systems use specially designed hardware 
to increase processing speed. These are typically 
available as Pc adapter cards to be fitted into the 
VRU. 

However, such cards in general must be de- 
signed for a particular system, dependent for ex- 
ample on the operating system (DOs or OS/2), 
computer architecture (ISA or MicroChannel), and 
so on. This greatly restricts the options available to 
the customer who wishes to incorporate such func- 
tion into a VRU. since the preferred adapter card 
may not be compatible with their VRU. Likewise it 
is difficult to optimise the different components of 
the system individually. The same problems may 
also occur even if only software components are 
involved: for example, a preferred voice mail prod- 
uct may not run under the same operating system 
as the preferred VRU. 



Accordingly, the invention provides a method 
of interactively processing a telephone call in a 
distributed system comprising at least two com- 
puter workstations connected together by a com- 
s munications link, in which the first computer is 
interfaced to the telephone network, said method 
comprising the steps of: 

receiving an incoming telephone signal from 
the telephone network; 
10 forwarding the incoming telephone signal over 

the communications link to a server means on the 
second computer workstation; 

processing the incoming telephone signal at 
the server means and generating a response based 
76 upon the telephone signal; 

transmitting the response from the server 
means to the first computer workstation, and pro- 
cessing said call at the first computer workstation 
in accordance with said response. 
20 The invention also provides a method of inter- 

actively processing a telephone call in a distributed 
system comprising at least two computer work- 
stations connected together by a communications 
link, in which a first computer workstation is inter- 
ns faced to the telephone network, said method com- 
prising the steps of: 

receiving an incoming telephone signal over 
said telephone network; 

sending a request over the computer network 
30 to a server means on the second computer work- 
station; 

generating a telephone signal at the server 
means based on said request and transmitting the 
telephone signal to the first computer workstation; 

35 forwarding the generated telephone signal at 

the first computer workstation out over the tele- 
phone network. 

The use of a distributed system in which the 
first computer is primarily responsible for handling 

40 the telephone call, and the second computer is 
primarily responsible for performing the desired 
technical processing, leads to great flexibility in 
system design, and so allows optimum technol- 
ogies to be used in all areas. The server means, 

45 which effectively constitutes a remote resource, 
may be used to provide voice recognition, text-to- 
speech, voice mail, FAX-back (where a FAX is sent 
back to the caller), or any other desired facility. 
These can be divided into inbound and outbound 

60 server applications. In the former, such as voice 
recognition, the server receives an incoming tele- 
phone signal (ie the voice of the caller) to process. 
In the latter, such as text to speech or FAX back, 
the server produces a telephone signal (synthesis- 

55 ed speech or a FAX message) which is transmitted 
back to the caller. Some applications involve both 
inbound and outbound processing; for example, a 
voice mail card will store incoming telephone sig- 

2 
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nals during the record phase, and but play them 
out later when the voice mail is examined. The 
telephone signal may (if desired) be compressed 
for transmission between the two computer work- 
stations. 

It is preferred that the method further com- 
prises the step of a resource controller, located on 
a computer workstation connected to a said first 
computer workstation by a computer link, maintain- 
ing a list of available server means and current 
usage thereof, wherein the first computer work- 
station requests access to the server means from 
the resource controller, and the resource controller 
responds to the first computer workstation whether 
or not the requested server means is available. The 
resource controller will typically be located on the 
second computer workstation, but might also be on 
some third workstation. In some situations it may 
be convenient to have a single resource control 
that handles all classes of server (eg voice recogni- 
tion, text to speech, and so on), but in general it is 
more convenient to have one resource controller 
for each class of server. 

The preferred initialisation process involves the 
first computer workstation broadcasting a request 
to locate the resource controller, and the resource 
controller responding to the request by sending a 
message to the first computer workstation specify- 
ing the location of the resource controller. An alter- 
native approach would be for the resource control- 
ler to send out a broadcast indicating its availability 
whenever it is brought up. 

The invention also provides a distributed sys- 
tem for interactively processing a telephone call, 
comprising at least two computer workstations con- 
nected together by a communications link, 

the first computer workstation including inter- 
face means for attachment to the telephone net- 
work and for receiving an incoming telephone sig- 
nal over said telephone network; means for for- 
warding a request over the computer network to a 
second computer workstation; and means for re- 
ceiving a telephone signal from the second com- 
puter, and forwarding said telephone signal to the 
interface means for transmission out over the tele- 
phone network; 

the second computer workstation including 
server means for generating a telephone signal 
based on the received request, and means for 
transmitting the telephone signal to the first com- 
puter workstation. 

The invention further provides a distributed 
system for Interactively processing a telephone 
call, comprising at least two computer workstations 
connected together by a communications link, 

the first computer workstation including inter- 
face means for attachment to the telephone net- 
work and for receiving an incoming telephone sig- 



nal over said telephone network; means for for- 
warding the telephone signal over the communica- 
tions link to a second computer workstation; and 
means for receiving a response from the second 
5 computer, and for processing the telephone call in 
accordance with the response; 

the second computer workstation including 
server means for receiving the incoming telephone 
signal over the communications link and generating 
10 generating a response based upon the incoming 
signal, and means for transmitting the response to 
the first computer workstation. 

The first and second computer workstations 
must be linked in a manner providing sufficient 
75 bandwidth to support the interactive or real-time 
processing of the telephone call. A particularly suit- 
able arrangement is for the first and second com- 
puter workstations to both be nodes on a local area 
network (LAN), preferably one having a 16 MBit/s 
20 bandwidth. Providing the traffic on the LAN is not 
unduly heavy, this should allow for example, in a 
text-to-speech application, synthesised voice to be 
played out over the LAN without undue delay. Note 
however, that the situation may become more dlf- 
25 ficult if the server can support several conversa- 
tions simultaneously, since in this case the band- 
width requirements are correspondingly increased. 

As referred to above, there is preferably a 
resource controller located on a computer work- 
30 Station in said local area network, the resource 
controller maintaining a list of available server 
means and current usage thereof, and responding 
to requests from the first computer workstation for 
access to the server means by notifying the first 
35 computer workstation whether or not the requested 
server means is available. Typically there is one 
resource controller in the network for each class of 
available server means. 

In one preferred configuration, the LAN in- 
40 eludes at least two computer workstations inter- 
faced to the telephone network, and the resource 
controller (or controllers) manage access from any 
of the at least two computer workstations to the 
server means. This has the advantage that multiple 
45 computer workstations can share a single server 
means (eg a single voice recognition unit), which 
avoids the cost of having to equip each voice 
response system with such a voice recognition 
unit. 

50 It should be appreciated that the open architec- 

ture of the present invention enables a great variety 
of possible configurations. For example, within a 
single LAN a number of voice response units may 
be supported by a suite of different server devices 

55 (text to speech, voice recognition, and so on). The 
servers may be all be located on one workstation, 
or may be distribut d across two or more ma- 
chines. 
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An embodiment of the Invention will now be 
described by way of example with reference to the 
following drawings: 

Figure 1 is a high-level overview of a distributed 
system according to the invention; 
Figure 2 is a detailed diagram of the configura- 
tion of the first computer workstation; 
Figure 3 is a detailed diagram of the configura- 
tion of the second computer workstation; 
Figure 4 is a flowchart illustrating the formation 
of a connection between a voice response unit 
and a server; 

Figure 5 is a flowchart illustrating in more detail 
the operation of the system with a voice rec- 
ognition server; and 

Figure 6 is a diagram showing a more com- 
plicated configuration involving several voice re- 
sponse units. 
Figure 1 shows a voice processing system in 
which a first computer workstation 10, a voice 
response unit. Is connected to a plurality of tele- 
phone lines 12 leading to a PBX 14. The telephone 
lines may be either analogue or digital: in the latter 
case, there will normally be only a single physical 
link, with some form of multiplexing. Also shown 
are trunk lines 16 leading from the exchange into 
the telephone network. It should be appreciated 
that in some instances the PBX will not be present, 
in which case the first computer workstation may 
be connected to lines leading directly into the 
telephone network. 

The first computer workstation is connected to 
a second computer workstation 20 by a local area 
network (LAN) 18. This may for example be a 
Token Ring network, such as available from IBM 
Corporation, an Ethernet, or any other form of 
network that provides sufficient bandwidth and re- 
sponse times to allow interactive real-time process- 
ing of a telephone call. 

tn one particular implementation of the inven- 
tion, the first computer workstation is a RISC Sys- 
tem/6000 running the DirectTalk/6000 software 
product (both available from IBM Corporation). The 
second computer workstation is a standard IBM 
compatible PC with an AT-BUS equipped for exam- 
ple with a VPRO-84 Voice Recognition Card, avail- 
able from Voice Processing Corporation, Mas- 
sachussetts. USA, Communications between the 
first and second computer workstations are carried 
out using the TCP/IP protocol. This is a conven- 
tional protocol based on point to point communica- 
tions between a port on a first process and a port 
on a second process (in fact it is possible for the 
two processes to be on the same machine). Both 
computer workstations are equipped with suitable 
adapter cards (as shown in Figures 2 and 3) which 
allow data to be sent between the two workstations 
in accordance with this protocol. Such communica- 
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tions systems are well-known in the art and will not 
be described in more detail. 

Figure 2 illustrates the main components of the 
first computer workstation running DirectTalk/6000 

6 on an RISC System/6000 under the AIX operating 
system. This system accepts digital T1 or El 
trunks 12 from the PBX: in the former case, ie in 
the US, 24 individual channels are multiplexed to- 
gether into a single trunk, with 8 bits per channel 

10 (standard u-law) and a sampling rate of 8 kHz. The 
system is attached to the PBX via a digital trunk 
processor 30 (the 9291 or 9295 cards), plus a 
digital trunk adapter card 32 located inside the 
RISC System/6000 itself. These two cards provide 

76 the interface to the telephone network, and are 
responsible eg for demultiplexing incoming calls, 
and multiplexing outgoing calls. Incoming calls are 
aggregated into 20 ms blocks of data before being 
passed on for further processing. 

20 Telephone signals are received from the digital 

trunk adapter card by a device driver 40, as known 
In the art, which Is responsible for buffering the 
signals so that they can be collected for processing 
by other system components. Likewise, the device 

25 driver is responsible for receiving outgoing mes- 
sages from the system and forwarding them to the 
digital trunk adapter card for transmission onto the 
telephone network. Data is read from and written to 
the device driver in accordance with standard pro- 

30 gramming techniques. 

Rgure 2 illustrates the main processes running 
on the RISC System/6000 that are necessary for an 
understanding of the invention (note the device 
driver is not an actual process itself, but rather a 

35 task running under the operating system kernel). 
The overall operation of the workstation is super- 
vised by an application program 42, which consists 
of a set of high level commands. These commands 
are interpreted by the channel processor 44 which 

40 is responsible for allocating resources inside the 
computer, and establishing connections as required 
between the various processes. In accordance with 
the present invention, it is possible for an applica- 
tion to request a resource that Is effectively exter- 

45 nal to the system: in other words the resource is to 
be supplied by a server on another machine. In this 
situation, the channel processor requests a custom 
server process 46 to obtain access to the remote 
resource. Actual data exchange between the first 

60 computer workstation and the server is controlled 
by a resource processor 48. 50. via a network 
Interface card 60. The number of resource proces- 
sors, which are started at initialisation by the cus- 
tom server, can be configured, for example accord- 

55 ing to the expected system load. During call pro- 
cessing, the resource processor transfers data di- 
rectly to or from the device driver to allow rapid 
flow of data between the telephone lines and the 

4 
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server. 

Figure 3 Illustrates the processes that are ac- 
tive on the second computer workstation 20 - the 
structure of this system is in fact very similar to 
that of the first computer workstation. There is a 
card 70 which in this particular implementation 
provides a voice recognition facility, but could be 
used for example to offer FAX. text to speech, and 
so on (there is a device driver associated with card 
70, but this has not been shown since it is not 
relevant to an understanding of the present inven- 
tion). A resource server acts as a front end to the 
card, allowing on other machines to interact with 
the card, sending voice data into it and receiving 
back recognised text. Typically the server and as- 
sociated card can handle several Incoming or out- 
going channels simultaneously. The second com- 
puter workstation also includes a resource control- 
ler 72, which maintains a table of all available 
servers, together with updated information on their 
current usage. Finally, the second computer work- 
station also includes a network interface card 80 to 
enable communications over the LAN 18. 

The sequence of events whereby a remote 
resource can he utilised is illustrated in Figure 4. 
The process begins with the CHP sending a re- 
quest to the custom server to provide access to the 
resource. In the present implementation, the CHP 
and the custom server communicate by means of 
an application programming interface (API) in the 
CHP. During initialisation, the custom server calls 
the CHP, effectively informing the CHP of its exis- 
tence. The custom server then regularly calls the 
CHP to see if it has any instructions for it (ie 
whether there is an outstanding request for an 
external resource). 

The custom server now sends a datagram out 
to the resource controller (a datagram is a special 
type of message available in AIX: it is used be- 
cause the resource controller may be supporting 
more than one voice response unit, and must be 
open to receiving requests from any machine). The 
datagram identifies the resource required by the 
custom server. The resource controller then checks 
its table of available resources, and their current 
status, and assuming for the moment that the re- 
quest can be satisfied, returns a message to the 
custom server containing information identifying the 
allocated server (the network address and IP port 
of the server). The resource controller then updates 
Its table of available resources. The custom server 
forwards the location Information onto the resource 
processor that will handle the particular server, 
allowing the resource processor to communicate 
directly with the server. The custom server and 
resource controller play no further part in this stage 
of communications. Finally, when the processing of 
the server has terminated, the communication be- 



tween the server and the resource processor can 
be concluded, and the custom server and resource 
controller notified accordingly. 

If instead it turns out that the remote resource 
6 requested by the custom server is not in fact 
available, for example the relevant server is already 
being fully utilised, then clearly the resource con- 
troller returns a negative response to the custom 
server. This response may indicate a suggested 
10 time to try again. 

Figure 5 shows in more detail the processing 
associated with a particular In-bound application 
(voice recognition of discrete digits) once commu- 
nication between the resource processor and the 
IS remote server has been established. A logical con- 
nection is made between the resource processor 
and the device driver (in AIX terminology, a stream 
is set up between a port on the device driver and a 
port on the resource processor). This allows the 
20 resource processor to read data directly from the 
device driver (this is much faster than allowing the 
CHP to do the routing, which is particularly impor- 
tant given the need for real-time processing of the 
call with minimum delay). Once this connection has 
25 been established, the resource processor repeat- 
edly polls the device driver to see if any data has 
arrived. Whenever it obtains a positive response, it 
collects the data, forms it into a packet (or packets) 
together with appropriate control - information, and 
30 then sends it over the network to the server. The 
server attempts to identify the digit which has been 
spoken based on the received signal: if the attempt 
is unsuccessful, the server must wait for more data. 
Once a successful recognition has been made, the 
35 server can return the spoken digit to the resource 
processor, which can forward the information to the 
channel processor (for return to the application), 
and close down communcations between the re- 
source processor and the server. 
40 The initialisation of the distributed system Is as 

follows. When the second computer workstation is 
initialised, each of the servers or resources notifies 
the resource controller of its existence, along with 
the number of ports that can be utilised for call 
45 processing. The resource controller can then make 
the appropriate entries in its resource table for 
each server. Next, when the first computer work- 
station is initialised, the custom server broadcasts a 
message over the LAN in order to locate the re- 
50 source controller. This produces a response from 
^he resource controller including the address of the 
machine on which the resource controller resides. 
Note that if the first computer workstation comes 
up before the resource controller, so that it does 
55 not receive any response to its broadcast message, 
it simply repeats the message until the resource 
controller has been started and can reply. 
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One potential problem with the distributed sys- 
tem so far described Is the possibility of packet 
loss somewhere in the network. To obviate this, 
whenever a packet containing either data or a com- 
mand is sent between the resource processor and 
the server, an acknowledgement is expected. Each 
packet is stored in a queue after transmission and 
only deleted after the acknowledgement has been 
received (the identification of packets is discussed 
in more detail below). If a specified number of re- 
transmissions occur, without any acknowledgement 
being received, it is assumed that the connection 
between the resource processor and the server has 
gone down, and appropriate error recovery proce- 
dures are initiated. 

According to the implemented communication 
protocol, each packet has a basic 8-byte header, to 
which further information or data may be appen- 
ded. The header includes fields identifying the type 
of packet (discussed in more detail below), various 
control flags, channel and sequence numbers 
(again discussed below), information about the 
length of the packet following the header, and error 
checking bytes. 

The channel id contained in each packet head- 
er specifies the channel to which the packet re- 
lates. The sequence number (which relates only to 
packets with that channel id) allows the loss of 
individual packets to be detected, and a re-trans- 
mission request sent if necessary. It also helps 
ensure that incoming packets are correctly sequen- 
ced at the receiving end. The channel id is re- 
quired bearing in mind that the resource processor 
and server may be handling several different tele- 
phone calls simultaneously. Each call is assigned 
Its own channel, to ensure that traffic on one line 
does not get confused with traffic on another line 
(this identification scheme could be extended if the 
network included several VRUs, as discussed be- 
low with reference to Figure 6). A unique channel 
id of 0 is assigned to communications between the 
custom server and the resource controller (this 
channel is not associated with any one particular 
telephone call). 

The different types packets will now be de- 
scribed for the various stages of operation de- 
scribed earlier. The initialisation procedure com- 
mences with the custom server sending out an 
IDENTIFY packet containing its own IP port and 
address (this is broadcast in datagram mode). The 
packet specifies a predetermined port number 
(1500. in the actual implementation), and any re- 
source controller having a port number matching 
this responds with an AVAIL packet identifying it- 
self and its whereabouts to the custom server. The 
IDENTIFY packet is resent using a linear or possi- 
bly exponential delay if no response is received 
straight away. 
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Once the resource controller has been located, 
the custom server sends a CHANOPEN packet to 
the IP address and port specified in the AVAIL 
response to the initial IDENTIFY packet. The pur- 

5 pose of this is simply to confirm the link to the 
resource controller. The initialisation procedure is 
completed when the custom server receives an 
acknowledgement to its CHANOPEN packet from 
the resource controller. 

70 The CHANOPEN/acknowledgement procedure 

is also used whenever a new channel is opened 
between a resource processor and a server to 
confirm that the channel is operational. Two types 
of packet, RESEND and RESTART, are provided to 

76 handle the situation where packets are lost, as 
mentioned above. The first of these, RESEND, 
identifies a particular packet to be resent, for exam- 
ple if examination of the sequence numbers in- 
dicates that a packet has not arrived, RESTART by 

20 contrast is used where data communications have 
been more seriously disrupted, and it is decided to 
recomnnence the sequence of packet transmission 
either from the beginning or from some specified 
packet sequence number. 

25 The CHANREQ packet is sent by the custom 

server to request a particular service from the 
resource controller (the packet contains an iden- 
tification of the desired service). If available, the 
acknowledgement to this packet will contain the IP 

30 port and address of the desired server; if the re- 
sponse is negative, the custom server must decide 
whether to retry later or abort the attempt. One 
further aspect is that the acknowledgement may 
indicate that the server requires application in- 

35 itialisation data to be downloaded from the custom 
server machine to the server machine: should this 
be the case, the custom server handles the trans- 
mission of the relevant data. 

After communications between the server and 

40 the resource processor have come to a conclusion, 
a CHANREL packet is sent by the resource proces- 
sor. The server should sends an acknowledgement 
back, closes the relevant port, and notifies the 
resource controller of its updated status. In some 

45 applications it may be desirable for the resource 
processor always to have the same server avail- 
able: in this case the CHANREL packet is not sent, 
so that the connection remains open. 

Data are transferred using a DATADL packet, 

50 which contains free-format data, whether text to be 
converted into speech, voice signals for recogni- 
tion, or whatever. In the case of voice recognition, 
many DATADL packets may be sent (each of 
which would be acknowledged) until recognition is 

55 successfully achieved and a result is available- This 
result is then returned to the resource processor 
attached to a RESULT packet. Text-to-speech op- 
erates slightly differently, in that both the text sent 

6 
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to the server, and the synthesised speech returned 
is transmitted in DATADL packets (again with each 
packet being acknowledged). 

Voice data are transmitted over the LAN using 
conventional (ie uncompressed) 8-bit u-law or A- 6 
law encoding (depending on the country). Although 
compression would help increase the rate of com- 
munication, it would be necessary for each server 
and voice reponse unit in the network to support 
the same compression algorithm. This would then io 
have the undesirable effect of restricting which 
VRU could use which server. However, in more 
sophisticated systems, it may be possible for the 
resource processor and server to negotiate about 
compression as part of their initial exchange of 75 
messages. If it was determined that both did in fact 
support the same algorithm this could then be 
adopted for that communication session. Another 
possibility is that in future the LAN interface cards 
will perform compression, although this should be 20 
transparent to the sending and receiving applica- 
tions. 

The size of packets used to transmit voice data 
over the LAN can be adjusted to optimise perfor- 
mance, based on the particular application, network 25 
traffic, and so on. For example, text to speech 
applications may send large packets (4 kbytes) 
every 0.5 seconds, since this is efficient in terms of 
LAN utilisation. By contrast, voice recognition may 
suit a smaller packet size, since not all the data 30 
may be required to identify the spoken input (espe- 
cially if the recognition is limited to distinguishing 
between just a few possibilities). Note>that the 
current system does not multiplex channels to- 
gether. Thus if several channels (ie telephone lines) 35 
are being handled by the same resource processor 
and server, each channel will have its own stream 
and ports at each end. This allows each channel to 
be closed individually when it is no longer required, 
and avoids the additional overheads and complex- 40 
Ity that would be required to support multiplexing. 

Figure 6 shows another distributed system for 
interactively processing a telephone call. This con- 
figuration is more complicated than that of Figure 
1, in that the LAN 180 now includes multiple voice 45 
response units 130, 140, 150, 160, which are ca- 
pable of supporting a large number of telephone 
lines 200. Furthermore, there are also multiple re- 
source controllers, RC1 and RC2 on nodes 110 
and 100 respectively, and multiple servers, RSI on 50 
first server machine 110 (offering perhaps TTS), 
and RS2 and RS3 on a second server machine 120 
(offering voice recognition). Such a configuration 
effectively shar s th servers amongst the VRUs, 
providing a wide range of function that would not 55 
be affordable if each VRU needed its own server. 

Typically resource controller RC1 would man- 
age allocation of server RSI, while resource con- 



troller RC2 would manage allocation of servers RS2 
and RS3. In the present implementation, there is a 
separate custom server in each VRU for each 
resource controller (although this is entirely depen- 
dent on the design of any particular custom serv- 
er). Thus the VRUs (130-160) would have support 
two custom servers in order to offer both voice 
recognition and TTS. The functioning of each of 
these is analagous to the operation of a single 
custom server system as previously described. 

Claims 

1. A method of interactively processing a tele- 
phone call in a distributed system comprising 
at least two computer workstations connected 
together by a communications link, in which 
the first computer is interfaced to the tele- 
phone network, said method comprising the 
steps of: 

receiving an incoming telephone signal 
from the telephone network; 

forwarding the incoming telephone signal 
over the communications link to a server 
rr^eans on the second computer workstation; 

processing the incoming telephone signal 
at the server means and generating a response 
based upon the telephone signal; 

transmitting the response from the server 
means to the first computer workstation, and 
processing said call at the first computer work- 
station in accordance with said response. 

2. The method of claim 1, wherein said server 
means' performs a voice recognition function. 

3- A method of interactively processing a tele- 
phone call in a distributed system comprising 
at least two computer workstations connected 
together by a communications link, in which a 
first computer workstation is interfaced to the 
telephone network, said method comprising 
the steps of: 

receiving an incoming telephone signal 
over said telephone network; 

sending a request over the computer net- 
work to a server means on the second com- 
puter workstation; 

generating a telephone signal at the server 
means based on said request and transmitting 
the telephone signal to the first computer work- 
station; 

forwarding the generated telephone signal 
at th first computer workstation out over the 
telephone network. 

4. A method as claimed in claim 3. wherein the 
server means performs a text to speech func- 
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tion. 

5. A method as claimed in any preceding clainn, 
further comprising the step of a resource con- 
troller, located on a computer workstation con- 5 
nected to a said first computer workstation by 

a computer link, maintaining a list of available 
server means and current usage thereof, 
wherein the first computer workstation requests 
access to the server means from the resource to 
controller, and the resource controller responds 
to the first computer workstation whether or not 
the requested server means is available. 

6. A method as claimed in claim 5, wherein the is 
resource controller is located on said second 
computer workstation. 



workstation; and means for receiving a re- 
sponse from the second computer, and for 
processing the telephone call in accordance 
with the response; 

the second computer workstation including 
server means for receiving the incoming tele- 
phone signal over the communications link and 
generating generating a response based upon 
the incoming signal, and means for transmit- 
ting the response to the first computer work- 
station. 

10- The distributed system of claim 8 or 9, wherein 
the first and second computer workstations are 
both nodes on a local area network (LAN), and 
said communications link is provided by the 
LAN. 



7. A method as claimed in claim 5 or 6, further 
comprising an initial step of the first computer 20 
workstation broadcasting a request to locate 

the resource controller, and the resource con- 
troller responding to the request by sending a 
message to the first computer workstation 
specifying the location of the resource control- 25 
ler. 

8. A distributed system for interactively process- 
ing a telephone call, comprising at least two 
computer workstations connected together by 30 
a communications link, 

the first computer workstation including In- 
terface means for attachment to the telephone 
network and for receiving an incoming tele- 
phone signal over said telephone network; 35 
means for forwarding a request over the com- 
puter network to a second computer work- 
station; and means for receiving a telephone 
signal from the second computer, and forward- 
ing said telephone signal to the interface 40 
means for transmission out over the telephone 
network; 

the second computer workstation including 
server means for generating a telephone signal 
based on the received request, and means for as 
transmitting the telephone signal to the first 
computer workstation. 

9. A distributed system for interactively process- 
ing a telephone call, comprising at least two so 
computer workstations connected together by 

a communications link, 

the first computer workstation including in- 
terface means for attachment to the telephone 
network and for receiving an incoming tele- 55 
phone signal over said telephone network; 
m ans for forwarding the telephone signal over 
the communications link to a second computer 



11. The distributed system of claim 10, further 
including a resource controller located on a 
computer workstation in said local area net- 
work, the resource controller maintaining a list 
of available server means and current usage 
thereof, and responding to requests from the 
first computer workstation for access to the 
server means by notifying the first computer 
workstation whether or not the requested serv- 
er means is available. 

12- The distributed system of claim 11, wherein 
the LAN includes at least two computer work- 
stations interfaced to the telephone network, 
and the resource controllers controls access 
from any of the at least two computer work- 
stations to the server means. 
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